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Section 1 
INTRODUCTION 


1.1 Identification 

This is the Software Assurance Plan of the Earth Observing System/ 
Advanced Microwave Sounding Unit-A (EOS/AMSU-A) System. This document is 
submitted in response to Contract NAS 5-32314, CDRL 309. 

1.2 Scope 

This document defines the responsibilities of Software Quality Assurance 
(SQA) for the development of the flight software installed in EOS/AMSU-A instruments, 
and the ground support software used in the test and integration of the EOS/AMSU-A 
instruments. 


The software being developed for the EOS/AMSU-A program consists of 
the eight CSCI identified below. There are four CSCI for each of the two instrument 
modules, EOS/AMSU-A1 and EOS/AMSU-A2. See Appendix A for a detailed description 
of the EOS/AMSU-A CSCI. 


CSCI NAME 

Command and Data Handling Firmware 
Instrument Control Firmware 
Special Test Equipment Software 
Spacecraft Workstation Software 

1.3 Purpose and Objectives 


EOS/AMSU-A 1 
CSCI N8 
CSCI N7 
CSCI N5 
CSCI N6 


EOS/AMSU-A2 
CSCI N12 
CSCI Nil 
CSCI N9 
CSCI N10 


The purpose of the Software Assurance Plan is to: 


a. Identify the CSCI and the documentation (collectively referred to as 
software products) being developed for this project and the types and 
characteristics of each. 

b. State the software development processes to be evaluated. 

c. Identify the software products to be evaluated 

d. Identify the software audits to be performed 
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e. State the quality assurance engineering responsibilities, tasks, and 
functions to be implemented by Software Quality Engineering in 
coordination with the Software Team Leader, the Program Manager, 
and the other product teams and organizational managers as required 
to assure software quality assurance requirements are met. 

f. Demonstrate the role of the Software Quality Assurance 
Organization and its relationship to the Product Teams 

1.4 Document Status and Schedule 

This is the Final submittal of the EOS/AMSU-A Software Assurance Plan. 

1.5 Documentation Organization 

The sections in this document are: 

Section 1 Introduction 

Section 2 Related Documentation 

Section 3 Quality Assurance Planning 

Section 4 Verification and Validation Planning 

Section 5 Quality Engineering Assurance Planning 

Section 6 Safety Assurance Planning 

Section 7 Security and Privacy Assurance 

Section 8 Certification Planning 

Section 9 Abbreviations and Acronyms 

Section 10 Glossary 

Section 11 Notes 

Section 12 Appendices 

The Software Quality Assurance documents developed for EOS/AMSU-A 
are this Software Assurance Plan and the Software Quality Assurance Procedures. 

The EOS/AMSU-A Software Documentation Tree is as shown in Figure 1. 
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Software Management Plan 


Acquisition Activities Plan 
Software Standards and Procedures 
Assurance Plan 

Configuration Management Plan 


Software 


Product Specifications 
Software Concept Document 
‘ Software Requirements Specification 
Software Architectural Design 
Software Detailed Design Document 
Firmware Support Manual 
Version Description Document 
Users’ Guide 


Firmware Product Specifications 

* Firmware Concept Document 

Firmware Requirements 
Firmware Detailed Design Document 
Firmware Version Description 

Software Test Plan 

4 L Software Test Procedures 

Software Test Reports 

Firmware Test Procedures 

1 Firmware Test Reports 


CDRL 008 
CDRL 508 
CDRL 402 
CDRL 309 
CDRL 005 

CDRL 306 


CDRL 306 


CDRL 033 
CDRL 415 
CDRL 217 
CDRL 415 
CDRL 217 


Figure 1 EOS/AMSU-A Software Documentation Tree 
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Section 2 

RELATED DOCUMENTATION 


2.1 Parent Documents 

Report 10339 Software Management Plan 

Jan 94 (NASA EOS/AMSU-A CDRL 008) 

2.2 Applicable Documents 

The following documents are referenced in or are applicable to this report. 
Unless otherwise specified, the latest issue is in effect. 


National Aeronautics and Space Administration 

CDRL Software Assurance Specifications 

Mar 93 


NASA-DID-M400 

420-05-01 
Aug 91 


422-10-01 
Feb 91 


Aerojet 


Report 10339 
Jan 94 

Report 10341 
Feb 94 

Report 9803 
May 91 


Management Plan DIDs Assurance Plan 

Earth Observing System (EOS) 
Performance Assurance Requirements 
for EOS General Requirements 

Earth Observing System (EOS) 
Instrument Project 

Software Acquisition Management Plan 


Software Management Plan 
(NASA EOS/AMSU-A CDRL 008) 

Acquisition Activities Plan 


Configuration Management Plan 
(NASA EOS/AMSU-A CDRL 005) 


SQA Procedure 100 Software Product Evaluations 


SQA Procedure 101 Software Process Evaluations 
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SQA Procedure 102 
SQA Procedure 103 

SQA Procedure 104 
SQA Procedure 105 
SQA Procedure 106 
SQA Procedure 107 
SQA Procedure 108 
Information Documents 
None 
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Reviews and Audits 

Software Problem Reporting and 
Corrective Action 

Software Quality Records 

Software Development Library 

Software Testing 

Non-Deliverable Software 

Acceptance Inspection and Preparation for 
Delivery 
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Section 3 

QUALITY ASSURANCE PLANNING 


3.1 Approach and Activities 

3.1.1 Organization 

This Software Assurance Plan shows the Software Assurance Management 
Organization and the relationship of Software Assurance to the other Product Teams (see 
Figure 2). It also shows that Software Assurance personnel are independent of Systems 
Engineering, Software Engineering, and Program Management and therefore have the 
freedom and authority to accomplish software quality requirements (see Figure 3). 

The following paragraphs, in conjunction with the flow diagram in Appendix 
B, describe and pictorially illustrate the Software Quality Assurance and Software 
Quality Engineering approach, activities, and methods that will be used in the 
development of CSCI for EOS/AMSU-A. Software Quality Engineering will perform the 
activities in the flow diagram in accordance with the detailed program schedule. 

3.1.2 General Approach to Software Engineering Planning 

There are five fundamental activities that Software Quality Engineering 
shall perform to assure that quality software products are produced. They are: 

a. Product Evaluations 

b. Process Evaluations 

c. Audits 

d. Software Problem Reporting & Corrective Action 

e. Software Product Team Meetings. 

After Software Development Engineering develops the required 
documentation and performs the software development engineering processes, Software 
Quality Engineering shall perform the Product Evaluations, Process Evaluations and 
Audits in accordance with SQA Procedures. Software Quality Engineering shall 
implement problem reporting and corrective action for any discrepancies found during 
the evaluations or audits performed during the Software Development Cycle. Software 
Quality Engineering shall attend Software Product Team Meetings to assure that the 
status of actions in progress, completed, and open actions are communicated to the 
Product Team. Any major problems shall be elevated to the Software Product Team 
Leader up through the Program Manager for resolution. The goal of this approach is to 
assure that, through a team effort, all evaluations and audits have been satisfactorily 
completed and that all problems are resolved in a timely manner and approved by 
Software Quality Engineering before moving to the next development phase. 
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Figure 2 Software Product Team Chart 
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Figure 3 Software Quality Assurance Organizational Charts 
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3.1.2.1 Product Evaluations - The products to be evaluated are the documents and 
the CSCI identified in Table I. Software Quality Engineering shall evaluate the 
identified documentation in accordance with Software Quality Assurance Procedures 
(SQAP) to assure adequate quality assurance requirements are included and for 
compliance to the contract. Software Quality Engineering will also verify the baselined 
CSCI through product evaluations per SQA Procedures described herein. 

3.1.2.2 Process evaluations - The processes to be evaluated are: (1) Preparation 
Maintenance of Software Development Folders (SDF), (2) Preparation and conduct of 
CSCI Design Reviews, (3) Code Walk-Throughs, (4) Formal Design Reviews, (5) 
Configuration and change process, (6) FQT Testing (e.g., pre-test review, testing, and 
post-test data reviews), and (7) Software Acceptance Reviews. Software Quality 
Engineering shall conduct process evaluations of these processes in accordance with the 
appropriate SQA Procedures. These evaluations shall be performed in the applicable 
development phases. The software development processes are shown in Tables II and III. 

3. 1.2.3 Audits - The management and technical audits shown in Table IV shall be 
performed. Audits of other disciplines such as Configuration Management, Software 
Development Engineering, and Test Engineering shall be performed by Software Quality 
Engineering in accordance with SQA Procedures. Software Quality Engineering shall also 
attend the formal reviews shown in Table IV. 

3.1.2.4 Software Problem Reporting and Corrective Action - Discrepancy reports 
shall be generated for any discrepancies found during these evaluations or audits. These 
reports contain documented cause and corrective action. Software Quality Engineering 
shall assure, through a team approach and team effort, that these discrepancy reports 
are generated, properly documented, and are resolved in a timely manner. Closure of 
these discrepancy reports requires Software Quality Engineering approval. Any 
discrepancy report that cannot be resolved at the Software Quality Engineering level 
shall be elevated to the Director of Product Assurance and reported to the Program 
Manager in order to assure timely and effective corrective action. All discrepancies 
shall be satisfactorily resolved with Software Quality Engineering approval prior to the 
software development effort moving to the next development phase. 

3.1.2.5 Software Product Team Meetings - Software Quality Engineering shall 
attend formal or informal team meetings with the Software Team Leader as required. 
These meetings shall be used to communicate the status of Software Quality Engineering 
activities and problems as well as the other Product Team members' concerns or 
problems requiring Software Quality Engineering action or support. Any major problems 
identified by Software Quality Engineering during any development phase shall be 
reported to the Performance Team Leader, Software Team Leader, and Program 
Manager through these meetings and through as required status reports. 
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TABLE I SOFTWARE PRODUCTS 


1. DOCUMENTS - DELIVERABLE CDRL 

CDRL 

SOFTWARE STANDARDS & PROCEDURES 

008 


TEST DOCUMENTS 
S/W TEST PLAN 
S/WTESTPROC 
S/W TEST REPORT 


033 

415 

217 


F/W TEST PLAN 

033 

F/WTESTPROC 

415 

F/W TEST REPORT 

217 


II. SOFTWARE - DEUVERABLE CSCI 

VERIFICATION METHOD 

CMD AND DATA HANDLING FIRMWARE, 
EOS/AMSU-A1 N8 

FORMAL FQT 
TESTING 

CMD AND DATA HANDLING FIRMWARE, 
EOS/AMSU-A2 N12 

FORMAL FQT 
TESTING 

INSTRUMENT CONTROL FIRMWARE, 
EOS/AMSU-A1 N7 

FORMAL FQT 
TESTING 

INSTRUMENT CONTROL FIRMWARE, 
EOS/AMSU-A2 Nil 

FORMAL FQT 
TESTING 

SPECIAL TEST EQUIPMENT, 
EOS/AMSU-A1 N5 

FORMAL FQT 
TESTING 

SPECIAL TEST EQUIPMENT, 
EOS/AMSU-A2 N9 

FORMAL FQT 
TESTING 

SPACECRAFT WORKSTATION, 
EOS/AMSU-A1 N6 

FORMAL FQT 
TESTING 

SPACECRAFT WORKSTATION, 
EOS/AMSU-A2 N10, 

FORMAL FQT 
TESTING 
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TABLE B FIRMWARE CSCI DEVELOPMENT PROCESSES 


COMMAND AND 
DATA HANDLING 

FIRMWARE CSCIN8.N12 

INSTRUMENT CSCI N7. Nil 

CONTROL FIRMWARE 

PROCESS 

YES 

NO 

COMMENTS 

SDF 

X 


MANUAL FOLDER 

RQMTS 

X 


POINTER TO SPEC 

PRELIM DESIGN 

X 


POINTER TO SPEC 

DETAIL DESIGN 

X 


POINTER TO SPEC 

CODEW/T 

X 


MEMO/WALK-THRU MINUTES 

UNIT TEST 


X 

ENGIN TEST INFORMAL - FQT PREP 

INTEGTEST 


X 

ENGIN TEST INFORMAL - FQT PREP 

REQUIREMENTS & 
DESIGN REVIEWS 

m 


ONLY NEW OR MODIFIED RQMTS & DESIGN WILL 
BE REVIEWED PER SQA PROCEDURES/ CHECKLISTS 

PRODUCT 

EVALUATIONS 

X 


EVALUATE PRODUCTS 

CDRL DOCUMENTS & CSCI SOFTWARE 

SEE TABLE I 

CODE/CODE W/T 

m 


ALL NEW OR MOD SOFTWARE AND FIRMWARE 
ONLY. NOT HERITAGE SOFTWARE 

UNIT & INTEGRATION 
TESTING 

X 


UNIT ENGIN TESTING INFORMAL - 

PREP FOR FQT. INTEGRATION TESTING AND 

FORMAL FQT TESTING ARE TO BE PERFORMED ON 

ALL SOFTWARE 

NOTE: * 

FORMAL REVIEWS 

X 


ATTEND DCR, PDR, CDR, TRR, & AR 

AUDITS 

X 


SEE TABLE IV 

CONFIGURATION 

CONTROLS 

mm 


CM CONTROLS INITIATED BY SQA 
TO BEGIN AT START OF QA DRY RUN FQT 

SDR 

X 


SOFTWARE DISCREPANCY REPORTS (SDR) 

SCR 

X 


SOFTWARE CHANGE REQUESTS (SCR) 

CSCI TESTING FQT 

X 


*NOTE 

ENGIN DRY RUN 

X 


PROOF PROC AND SOFTWARE FUNCTIONALITY 

QA DRY RUN 

X 


SQA WITNESS FQT PER RELEASED PROCEDURES 

FORMAL RUN 

X 


FORMAL RUN WITH SQA AND CUSTOMER 

SOFTWARE 
ACCEPTANCE 
REVIEW (SWAR) 

X 


PARTICIPATE IN THE REVIEW AND RESOLVE AND 
CUSTOMER CONCERNS/SOFTWARE ASSURANCE 
ACTION ITEMS (REF CDRL 028/SOW SECTION IV M) 

DD250 REVIEW 

X 


REVIEW DD250 FOR CORRECTNESS/ 
COMPLETENESS AND SIGN PRIOR TO PRESENTING 
TO THE CUSTOMER (REF SOW SECTION B1 & El) 

DELIVERY AND 
SHIPPING 

mm 


THIS SOFTWARE IS DELIVERED AS EMBEDDED 
FIRMWARE WITH THE DELIVERABLE HARDWARE 

* ALL CSCI WILL BE SUBJECTED TO FQT 
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TABLE m SOFTWARE CSCI DEVELOPMENT PROCESSES 


SPECIAL TEST 
EQUIPMENT 

FIRMWARE CSCIN5.N9 


SPACECRAFT WORKSTATION CSCI N6. N1 0 

SOFTWARE 


PROCESS 

YES 

NO 

COMMENTS 

SDF 

X 


MANUAL FOLDER 

RQMTS 

X 


POINTER TO SPEC 

PRELIM DESIGN 

X 


POINTER TO SPEC 

DETAIL DESIGN 

X 


POINTER TO SPEC 

CODE W/T 

X 


MEMO/WALK-THRU MINUTES 

UNIT TEST 


X 

ENGIN TEST INFORMAL - FQT PREP 

INTEG TEST 


X 

ENGIN TEST INFORMAL - FQT PREP 

REQUIREMENTS & 
DESIGN REVIEWS 

X 


ONLY NEW OR MODIFIED RQMTS & DESIGN WILL 
BE REVIEWED PER SQA PROCEDURES/ CHECKLISTS 

PRODUCT 

EVALUATIONS 

X 


EVALUATE PRODUCTS 

CDRL DOCUMENTS & CSCI SOFTWARE 

SEE TABLE 1 

CODE/CODE W/T 

X 


ALL NEW OR MOD SOFTWARE AND FIRMWARE 
ONLY. NOT HERITAGE SOFTWARE 

DATA BASE TABLE 

★ 


*NOTE: SPACECRAFT WORKSTATION SOFTWARE 
N/A PSEUDO WALK-THRU DATA BASE 

UNIT & INTEGRATION 
TESTING 

X 


UNIT ENGIN TESTING INFORMAL - 

PREP FOR FQT. INTEGRATION TESTING AND 

FORMAL FQT TESTING ARE TO BE PERFORMED ON 

ALL SOFTWARE 

NOTE: * 

FORMAL REVIEWS 

X 


ATTEND OCR, PDR, CDR, TRR, & AR 

AUDITS 

X 


SEE TABLE IV 

CONFIGURATION 

CONTROLS 

mm 


CM CONTROLS INITIATED BY SQA 
TO BEGIN AT START OF QA DRY RUN FQT 

SDR 

X 


SOFTWARE DISCREPANCY REPORTS (SDR) 

SCR 

X 


SOFTWARE CHANGE REQUESTS (SCR) 

CSCI TESTING FQT 

X 


*NOTE 

ENGIN DRY RUN 

X 


PROOF PROC AND SOFTWARE FUNCTIONALITY 

QA DRY RUN 

X 


SQA WITNESS FQT PER RELEASED PROCEDURES 

FORMAL RUN 

X 


FORMAL RUN WITH SQA AND CUSTOMER 

SOFTWARE 
ACCEPTANCE 
REVIEW (SWAR) 

■ 


PARTICIPATE IN THE REVIEW AND RESOLVE AND 
CUSTOMER CONCERNS/SOFTWARE ASSURANCE 
ACTION ITEMS (REF CDRL 028/SOW SECTION IV M) 

DD250 REVIEW 

■ 


REVIEW DD250 FOR CORRECTNESS/ 
COMPLETENESS AND SIGN PRIOR TO PRESENTING 
TO THE CUSTOMER (REF SOW SECTION B1 & El) 

DELIVERY AND 
SHIPPING 

X 


THIS SOFTWARE WILL BE DELIVERED TO THE SPACE 
INTEGRATOR SITE ALREADY INSTALLED AND 
FULLY TESTED IN THE GSE COMPUTERS. BACK-UP 
COPIES OF THE GSE SOFTWARE STORED ON MAG 
TAPE. USER AND OPERATOR MANUALS WILL BE 
SHIPPED ALSO. 


* ALL CSCI WILL BE SUBJECTED TO FQT 
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TABLE IV SOFTWARE AUDITS 


Audits 

Comments 

Initial Contract 

Completed 1 Mar 94 as part of preparation of this plan. 

Management 


Configuration Mgt 

Initial 

Follow-up 

These audits will be performed to Software Quality Assurance 
Procedures which contain checklists to be used. An initial and 
follow-up audit(s) will be performed. 

SW Development Mgt 

Initial 

Follow-up 

These audits will be performed to Software Quality Assurance 
Procedures which contain checklists to be used. An initial and 
follow-up audit(s) will be performed. 

Technical 


Requirements and 
Design Reviews 

Evaluate requirements, preliminary, and detail design per SQA 
Procedures. Reference paragraph 3.1 herein. 

Code Walk-thrus 

Review Code for compliance with standards. Reference 3.1 
herein. 

SDF Audits 

Perform audit per SQA Procedure/checklist. Reference 3.1 
herein. 

Configuration Baseline 

Verify the Configuration Baseline of the Deliverable CSCI prior to 
the SWAR in coordination with the local SQA customer 
representative. 

Formal Reviews 

Attend the formal reviews (DCR, PDR, CDR, TRR, AR) to interface 
with the customer and resolve any problems/software quality 
assurance action items. Reference 3.1 herein. 

Software Problem Reporting 
and Corrective Action System 

Audit the SDR and SCR Controls/System per Software Quality 
Assurance Procedures. The procedures contain checklists to be 
used for this audit. Correctness, completeness, and effective and 
timely closure of these documents will be audited. 
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3.1.3 Time-phased Approach 

The Software Development Cycle Milestones, as shown in the flow diagram 
in Appendix B, are the Implementation Phase, Design Concept Review (DCR), 
Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness 
Review (TRR), and Acceptance Review (AR). 

3.1.3.1 Initial Contract Review-Pre-Implementation Phase - Software Quality 
Engineering tasks start with a complete review of the Contract, attachments, SOW, and 
CDRL to determine Software Quality Assurance requirements. Software Quality 
Engineering shall coordinate with the Software Development Engineering Team Leader 
and other product team members to determine the products, processes, methods, and 
techniques to be used for the Software Development Cycle Phases and to assure 
continuity between the various product team disciplines. 

3. 1.3.2 Implementation Phase through DCR Phase - During this phase, Software 
Quality Engineering shall review the contract and shall generate a Software Assurance 
Plan. This plan incorporates the software quality assurance contractual requirements 
and the planning to implement them. Software Quality Engineering shall start 
generating project-unique SQA Procedures that contain detailed how to instructions that 
will be followed by Software Quality Engineering. These procedures will be completed, 
as required, to support the Software Quality Engineering tasks for each phase. All SQAP 
will be completed by PDR. Additionally, Configuration Management and Software 
Development Engineering, in parallel with Software Quality Assurance, perform a review 
of the contract and develop their respective management plans in a similar manner. 
These activities are shown in the flow diagram in the applicable area for each discipline. 

Systems Engineering and Software Development Engineering generate the 
Software Management Plan, Configuration Management Plan, and Software Assurance 
Management Plan. Technical documents for this phase are the preliminary Standards and 
Procedures Manual and Firmware and Software Test Plans. These are shown in the flow 
diagram in Appendix B in the Software Development Engineering area. 

After Software Development Engineering generates the above documents, 
Software Quality Engineering shall perform Product Evaluations of these documents in 
accordance with SQAP 100. Any discrepancies found by Software Quality Engineering 
during these product evaluations are documented, dispositioned, and closed per SQAP 
103. 


Software Development Engineering now initiates Software Development 
Folders (SDF) for each CSCI. Software Quality Engineering shall audit this process in 
accordance with SQA Procedures which include program-unique checklists (Reference 
SQAP 102). Any discrepancies found by Software Quality Engineering during this process 
evaluation are documented, dispositioned, and closed per SQAP 103. 
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The goal for this phase is to obtain Software Quality Engineering approval 
of all the above evaluations and audits with no open discrepancies. This will assure that 
sound Software Engineering Management, Configuration Management, and Software 
Quality Assurance Management Plans are in place and that the documents generated, and 
processes performed, are acceptable so that the development of the software is ready to 
move to the next phase. Additionally, Software Development Folders shall be in place 
with the required requirements and preliminary design documents and data. The 
completion of these activities will assure timely and effective development of quality 
software products. The status of Software Quality Assurance activities shall be reported 
at weekly meetings and and in weekly activity reports to the Product Team Leader, 
Performance Assurance Team Leader, and the Program Manager. 

Software Quality Engineering shall attend the DCR and interface with the 
customer to assure that any software quality problems or issues are resolved in a timely 
manner. This phase is completed upon satisfactory completion of the formal DCR 
meeting and when all software quality action items closed. 

3.1.3.3 DCR through PDH Phase - Software Quality Engineering shall perform an 
initial audit of Configuration Management and Software Engineering Management, in 
accordance with SQAP 102, to verify adherence to their respective plans. This assures 
that satisfactory management is in place and implemented to assure tasks are assigned 
and completed in a timely manner to not only meet project schedule but also to produce 
quality software products. 

The documents generated for this phase are the preliminary Software and 
Firmware Test Procedures, and the Software Design and Code Standards. 

After Software Engineering generates these documents, Software Quality 
Engineering shall perform product evaluations of these documents in accordance with 
SQAP 100. Any discrepancies found by Software Quality Engineering during these 
product evaluations are documented, dispositioned, and closed per SQAP 103. 

In this phase, Software Development Engineering performs the following 
processes on the software for the CD<5cH breadboard. 

a. generates software Design and Code for the Command and Data 
Handling (C&DH) and the Instrument Control CSCI. 

b. performs Design and Code Walk-Throughs of the C&DH and 
Instrument Control CSCI. 

c. updates the CSCI SDF with the Design and Code data. 

When complete, Software Development Engineering and Software Quality 
Engineering shall jointly perform a Design and Code walk-through of each CSCI in 
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accordance with SQAP 101. Any discrepancies found by SQA Engineering during the 
process evaluation shall be documented, dispositioned, and closed per SQAP 103. 

After Software Development Engineering updates the SDF folders, 
Software Quality Engineering shall perform an audit of the SDF in accordance with 
SQAP 102. Any discrepancies found by Software Quality Engineering during the SDF 
Audits are documented, dispositioned, and closed per SQAP 103. 

The goal for this phase is to obtain Software Quality Engineering approval 
of all the above evaluations and audits with no open discrepancies. This will assure that 
the documents generated, and the processes and audits performed, are acceptable so that 
the development of the software is ready to move to the next development phase. 
Additionally, Software Development Folders are in place with current design documents 
and code data. The completion of these activities assure timely and effective 
development of quality software products. The status of Software Quality Assurance 
activities shall be reported at weekly meeting and in weekly activity reports to the 
Product Team Leader, Performance Assurance Team Leader, and the Program Manager. 

Software Quality Engineering shall attend the PDR and interface with the 
customer to assure that any software quality problems or issues are resolved in a timely 
manner. This phase is completed upon satisfactorily completion of the formal review 
meeting and when all software quality action items closed. 

3.1.3.4 PDR through CDR Phase - Software Development Engineering generates 

the preliminary Firmware and Software Test Procedures. 

After Software Development Engineering generates the above documents, 
Software Quality Engineering shall perform product evaluations of these documents in 
accordance with SQAP 100. Any discrepancies found by SQA Engineering during these 
product evaluations are documented, dispositioned, and closed per SQAP 103. 

In this phase, Software Development Engineering performs the following 

processes. 

a. code and unit testing of the Instrument Control CSCI. 

b. code and unit testing of the Special Test Equipment (STE) CSCI. 

c. code walk-throughs of the Instrument Control, STE CSCI. 

d. updates the CSCI SDF with the Code and walk-through data. 

When complete, Software Development Engineering and Software Quality 
Engineering shall jointly perform a Code walk-through of each CSCI in accordance with 
SQAP 101. Any discrepancies found by SQA Engineering during the process evaluation 
shall be documented, dispositioned, and closed per SQAP 103. 
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After Software Engineering updates the SDF folders, Software Quality 
Engineering shall perform an audit of the SDFs in accordance with SQAP 102. Any 
discrepancies found by SQA Engineering during the SDF Audits are documented, 
dispositioned, and closed per SQAP 103. 

The goal for this phase is to obtain Software Quality Engineering approval 
of all the above evaluations and audits with no open discrepancies. This will assure that 
the documents generated, and the processes and audits performed, are acceptable so that 
the development of the software is ready to move to the next development phase. 
Additionally, Software Development Folders are in place with current design documents 
and code data. The completion of these activities assure timely and effective 
development of quality software products. The status of Software Quality Assurance 
activities shall be reported at weekly meeting and in weekly activity reports to the 
Product Team Leader, Performance Assurance Team Leader, and the Program Manager. 

Software Quality Engineering shall attend the CDR and interface with the 
customer to assure that any software quality problems or issues are resolved in a timely 
manner. This phase is completed upon satisfactorily completion of the formal review 
meeting and all software quality action items closed. 

3.1.3.5 CDR through TRR Phase - Software Development Engineering generates or 
updates the final Firmware & Software Test Procedures and the preliminary Software 
Test Reports. 


After Software Development Engineering generate the above documents, 
Software Quality Engineering shall perform product evaluations of these documents in 
accordance with SQAP 100. Any discrepancies found by SQA Engineering during these 
product evaluations are documented, dispositioned, and closed per SQAP 103. 

Software Engineering performs the following processes during this phase: 

a. codes and performs unit and integration testing of the Spacecraft 
Workstation CSCI 

b. develops STE integration code and test 

c. conducts integration code walk-through of STE and Spacecraft 
Workstation CSCI 

d. updates the SDF for STE and Spacecraft Workstation CSCI 

e. develops integration code for the Spacecraft Workstation CSCI 

f. performs code walk-through of Spacecraft Workstation integration 
code 
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g. updates SDF with integration code data for the Spacecraft 
Workstation CSCI 

h. integrates and tests the STE, Instrument Control, and C&DH CSCI 
and performs engineering dry run FQT testing 

i. perform QA dry run FQT testing of the STE, Instrument Control and 
CicDH CSCI 

When complete, Software Development Engineering and Software Quality 
Engineering shall jointly perform a Code walk-through of each CSCI in accordance with 
SQAP 101. Any discrepancies found by Software Quality Engineering during the process 
evaluation shall be documented, dispositioned, and closed per SQAP 103. 

After Software Development Engineering updates the SDF folders, 
Software Quality Engineering shall perform an audit of the SDF in accordance with 
SQAP 102. Any discrepancies found by SQA Engineering during the SDF Audits are 
documented, dispositioned, and closed per SQAP 103. 

The FQT process is performed during this phase. This is accomplished by 
Software Test Engineering performing and satisfactorily completing the engineering FQT 
dry run for the STE, Instrument Control, and CicDH CSCI. Then the QA FQT dry run for 
these CSCI shall be performed by Software Test Engineering with Software Quality 
Engineering witnessing the FQT testing. Software Quality Engineering shall perform this 
activity in accordance with SQAP 106. Any discrepancies found by Software Quality 
Engineering during this FQT shall be documented, dispositioned, and closed per SQAP 
103. Software Problem Reporting and the use of Software Discrepancy Reports (SDR) 
and Software Change Requests (SCR) for configuration control is initiated at this point 
in the software development cycle. 

During this phase, Quality Software Engineering shall perform a follow up 
Audit of Configuration Management and Software Development Engineering in 
accordance with SQAP 102 to verify implementation of the respective plans and 
compliance thereto. Any discrepancies found by Software Quality Engineering during 
these audits shall be documented, dispositioned, and closed per SQAP 103. 

Software Quality Engineering shall attend and participate in the TRR along 
with the Software Test Engineer and shall interface with the customer to assure any 
testing or software quality testing problems or issues are resolved in a timely manner. 
Software Quality Engineering activities for the TRR shall be performed in accordance 
with SQAP 106. This phase is completed upon satisfactorily completion of the formal 
TRR meeting and when all software quality action items are closed. 
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3.1.3.6 TRR through AR Phase - Software Test Engineering and Software Quality 

Engineering shall perform the FQT processes for the STE, Instrument Control, and C&DH 
CSCI during this phase. The process includes pre-test reviews, FQT testing and post-test 
reviews in accordance with SQAP 106 for each FQT test series. To accomplished this, 
Software Test Engineering and SQA Engineering shall jointly perform a pre-test 
readiness review with Software Quality Engineering and the Customer witnessing the 
formal FQT testing. Software Test Engineering and Software Quality Engineering shall 
jointly perform a post-test readiness review for the STE, C&DH, and Instrument Control 
CSCI with the Customer attending. The Program Manager and Performance Assurance 
Team Leader and other customer personnel may be invited as coordinated and agreed 
upon by the Program Manager and the Customer. Any discrepancies found by Software 
Quality Engineering during this Formal Qualification Testing shall be documented, 
dispositioned, and closed per SQAP 103. 

The same test engineering dry run and QA dry run testing process is 
performed for the Spacecraft Workstation CSCI. After Software Test Engineering 
satisfactorily completes the engineering FQT dry run for the Spacecraft Workstation 
CSCI, the QA FQT dry run for this CSCI shall be performed by Software Test 
Engineering with Software Quality Engineering witnessing the FQT testing. Software 
Quality Engineering shall perform this activity in accordance with SQAP 106. Any 
discrepancies found by SQA Engineering during this FQT testing shall be documented, 
dispositioned, and closed per SQAP 103. 

The documents generated in this phase are the final Software <5c Firmware 
Test Reports, and any Software Change Requests or Software Discrepancy Reports as 
required. 


After Software Development Engineering generates the above documents, 
Software Quality Engineering shall perform product evaluations of these documents in 
accordance with SQAP 100. Any discrepancies found by Software Quality Engineering 
during these product evaluations are documented, dispositioned, and closed per SQAP 
103. 


During this phase, Software Test Engineering and Software Quality 
Engineering shall perform the FQT process for the Spacecraft Workstation CSCI. To 
accomplish this Software Test Engineering and Software Quality Engineering shall jointly 
perform a pre-test readiness review. Then Software Test Engineering shall perform the 
formal FQT testing with Software Quality Engineering and the Customer witnessing the 
formal testing. Software Test Engineering and Software Quality Engineering shall jointly 
perform a post-test readiness review for the Spacecraft Workstation CSCI with the 
Customer attending. The Program Manager and Performance Assurance Team Leader 
and other customer personnel may be invited to attend the formal pre-test, testing, and 
post-test activities as coordinated and agreed upon by the Program Manager and the 
Customer. Any discrepancies found by SQA Engineering during this formal testing shall 
be documented, dispositioned, and closed per SAP 103. 
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Software Quality Engineering shall prepare for, and participate in, the 
formal Acceptance Review (AR) along with the Software Test Engineer, in coordination 
with Configuration Management, and the Program Manager. Software Quality 

Engineering shall interface with the customer to assure that any testing, test 
requirements verification, and software quality issues are resolved in a timely manner. 
Software Quality Engineering activities for the AR shall be performed in accordance 
with SQAP 108. Software Test Engineering, the Program Manager, and Software Quality 
Engineering shall perform an AR internal dry run to verify all software requirements 
including interface requirements are met. This activity is performed in accordance with 
SQAP 108. This phase is completed upon satisfactorily completion of the formal AR 
meeting and when all software quality action items are closed. 

Software Quality Engineering shall review and approve the CSCI DD-250 
after verifying compliance to the contract. Software Quality Engineering shall present 
the DD-250 to the customer for signature. 

The final Software Quality Engineering task is to perform preparation for 
delivery of the CSCI and the supporting documentation in accordance with SQAP 108. 
This completes the software development cycle. 

3.1.4 Quality Records 

SQA Engineering shall maintain Quality Records on file as quality objective 
evidence. These records shall be available for internal audits and customer review in 
accordance with SQAP 104. 

3.1.5 Reliability 

There are no reliability contract requirements. 

3.1.5.1 Firmware CSCIs 

Reliability for the Firmware CSCI is 100 tested during FQT Testing. 

3. 1.5.2 STE Software 

There is no reliability requirement for the STE because it is not mission 
critical. The GSE is easily revised and it is used for ground testing only. 

3.1.6 Maintainability 

3.1.6.1 Software Maintainability 

There are no maintainability contract requirements for the soltware. 
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The firmware cannot be maintained once it is burned in, therefore this 
requirement is not applicable. Maintainability for the STE is satisfied through 
compliance to Design and Coding Standards that assure ease of maintenance by any 
programmer. 

3.1.6.2 Hardware Maintainability 

Maintainability is done through a maintenance contract. The system disks 
have been replaced by the vendor more than once with no adverse effect on the system 
operation. Similar STE software for other projects run on a Microvax II using VMS 4.4 
and a Vax 4000/200 using VMS 5.5 with no source code changes. Only requirement is to 
link the object modules on the target computer. No maintenance problem if new 
computers are required in the future. 

3.2 Methods and Techniques 

The methods and techniques to be used for the Software Development of 
the EOS/AMSU-A CSCI have been identified and addressed in detail in 3.1. 

3.3 Products 

As described in 3.1, product evaluations will be performed per Software 
Quality Assurance Procedures which will include checklists. Products to be evaluated 
are the deliverable documents and software described in Table I. 
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Section 4 

VERIFICATION AND VALIDATION PLANNING 


The requirements identified in the Software Requirements Specification 
and the Software Interface Requirements Specification will be verified by test, 
demonstration, inspection, or analysis per the Software Test Plan. The Software 
Assurance Review (SWAR) is held to demonstrate to the customer that all requirements 
have been verified. Software Quality Engineering is a major contributor to this review 
along with Software Development Engineering and Test Engineering. Software Quality 
Engineering shall verify in coordination with the Software Project Team Leader and 
Program Manager that all requirements are verified prior to conducting this review with 
the customer. 


The only validation required is of the Software Test Beds for all Formal 
Testing of the CSCI. This will be done in coordination with the Software Test Engineer 
using the Software Test Plan and Software Test Procedures. 

4.1 Approach and Activities 

As a part of verification and validation. Software Quality Engineering shall 
review, per SQA Procedures, the Software Requirements Specification, Interface 
Requirements Specification, Software and Firmware Test Plans, Software and Firmware 
Test Procedures, and Software and Firmware Test Reports for requirements traceability, 
adequate quality assurance requirements, and for compliance to the CDRL/DID. 

In addition to all the software development activities throughout the 
development phases, the primary activity involved with verification and validation tasks 
is the Formal Qualification Testing (FQT) per the Software Test Plan and Test 
Procedures. Software Quality Engineering shall perform the following activities: 

a. Witness the FQT QA Dry Run and formal FQT per SQAP 106 

b. Review the test results and verify that all software requirements are 
met in preparation for the SWAR per SQAP 108 

c. Participate in the formal SWAR per SQAP 108. 

Unit and Integration tests will be informal, engineering tests in preparation 
for the Engineering and QA Dry Run FQT testing. Unit, integration, and acceptance 
testing are defined in Tables II and III for each CSCI. 

Software Quality Engineering shall assure that Software Standards and 
Procedures exist and are followed by Software Development Engineering in developing 


22 



Report 10428A 
August 1994 


the requirements, design, and code. This will be evaluated through reviews and code 
walk-throughs. 

For Reliability and Maintainability requirements refer to 3,1.5 and 3.1.6, 

respectively. 


SQAP 106 and 103 contain Software Quality Engineering responsibilities 
and instructions that define action to be taken for test anomalies and failures such as 
initiating SDR/SCR. The disposition of these documents may require rerunning tests or 
portions thereof as approved by Software Quality Engineering. 

The Software and Firmware Test Reports shall be reviewed by Software 
Quality Engineering for compliance with the CDRL/DID, for completeness, correctness, 
and for adequate quality assurance requirements per SQAP 100. 

As discussed above, initial audits of the contract itself and functional 
management will be performed per SQAP 102. The completion of the defined audits, 
evaluations, and reviews of the development processes and products shall be performed 
per the SQA Procedures defined in 3.1. The combination of all these activities shall 
assure verification and validation of the CSCI. 

4.2 Methods and Techniques 

The method for verification of the software CSCI is for Software 
Engineering, Test Engineering, Program Manager, and Software Quality Engineering to 
perform an internal requirements verification review of the formal FQT testing results. 
Upon successful completion of the internal review, Aerojet will perform the formal 
Software Assurance Review (SWAR) with the customer. Also, verification of the 
Deliverable Documents is accomplished by Software Quality Engineering reviewing, and 
approving, the Software and Interface Requirements Specifications, Software and 
Firmware Test Plans, and the Software and Firmware Test Procedures prior to the 
SWAR. 


The techniques to be used are Formal Qualification Testing of the Software 
in accordance with released test procedures. The test bed will be validated using the 
released test procedures in coordination with the Test Engineer. 

Software Quality Engineering will assure that Software Problem Reports 
are generated for test anomalies starting at the QA FQT Dry Runs and for all subsequent 
FQT. This includes use of Software Discrepancy Reports (SDR), identifying cause and 
corrective action, and close out of all anomalies/failures. Software Quality Engineering 
will assure that Software Change Requests (SCR) are initiated and controlled per SQA 
and Configuration Management procedures. 

Software Quality Engineering will perform audits of Configuration 
Management (CM) as required, and scheduled, to verify compliance to the contract and 
the Configuration Management Plan. These audits will include audits of CM change 
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controls, CM Software Change Control Board procedures, and CM media controls, 
including storage. These audits will be performed in accordance with SQA Procedures 
which will include applicable checklists. The checklists will contain characteristics 
derived from previous experience on similar projects, NASA-DID-M400, and the PAR 
Section 10, as applicable to the particular evaluation being performed. 

4.3 Products 

The products are the FQT test results, any SDR generated during formal 
testing, the Software Test Report, and the Firmware Test Report. Software Quality 
Engineering will review these products in accordance with SQA Procedures. 

Any discrepancies identified during these product reviews, formal testing, 
or test data reviews will be documented and maintained per SQAP 103 for evaluation by 
Software Development Engineering and Software Quality Engineering for future project 
lessons learned and future project usage. 


24 


Report 10428A 
August 1994 


Section 5 

QUALITY ENGINEERING ASSURANCE PLANNING 


5.1 Approach and Activities 

5.1.1 See 3.1 and the Software Assurance Flow Diagram in Appendix B. 

There are no reliability contract requirements. 

5.1.3 The only maintainability issue is maintenance of the code during develop- 

ment (i.e., in case of corrections, revisions, or replacement of the original software 
development engineer). Maintainable design and code is accomplished by the software 
developer complying with the Software Development Manual section on Design and Code 
Standards. Software Quality Engineering will verify compliance to these standards by 
performing design and code walk-thrus per SQA Procedures. Once the software is burned 
into the PROM there are no maintainability requirements since the software cannot be 
changed at this point. Refer to 3.1.6 for hardware maintainability. 

5.2 Methods and Techniques 

The method used for Software Quality Engineering planning is discussed in 
detail in 3.1 and shown in the Software Assurance Flow Diagram in Appendix B. 

For techniques, see 3.1 and 3.2. Additional techniques to be used include 
evaluations of the design and code for maintainability. The evaluations are to be 
performed per SQA Procedures which detail responsibilities and tasks to be performed by 
Software Quality Engineering. 

All CSCI for EOS/AMSU-A are being developed by Aerojet personnel. 
Note: Per the Acquisition Activities Plan (CDRL 508) the only software being procured 
for the EOS software development is the OASIS/CSTOL software for the Spacecraft 
Workstation. All Quality Assurance and Configuration Management for the 
OASIS/CSTOL Software is performed by NASA. 

5.3 Products 

See 3.1 for a detailed discussion on products. The Software Assurance 
products are the Software Quality Assurance Plan and the Software Quality Assurance 
Procedures. Additionally, any SDR or other evaluation reports, generated by Software 
Quality Engineering as a result of witnessing formal testing, performing evaluations, or 
audits, are products and will be assessed by Software Quality Engineering and maintained 
in the SQA files. All other products are generated or developed by Software 
Development Engineering. 
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Section 6 

SAFETY ASSURANCE PLANNING 


None. The operating or malfunctioning of the EOS/AMSU-A software CSCI 
poses no potential hazards to personnel or deliverable hardware instruments. 
Additionally, any command or any number of commands can be sent in any sequence with 
no potential damage to the hardware. The only concern is that if someone was to 
command the instrument to move with a person or object in the way there is a potential 
for damage to the hardware or possible harm to personnel. This potential hazard is 
controlled by use of procedures. 

6.1 Approach and Activities 

N/A 

6.2 Methods and Techniques 
N/A 

6.3 Products 

N/A 
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Section 7 

SECURITY AND PRIVACY ASSURANCE PLANNING 


7.1 Approach and Activities 

N/A 

7.2 Methods and Techniques 

N/A 

7.3 Products 

N/A 
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Section 8 

CERTIFICATION PLANNING 


8.1 Approach and Activities 

After successful completion of formal FQT testing, certification of the 
software will be performed by Software Quality Engineering in accordance with Software 
Quality Assurance Procedures. Software Quality Engineering will certify, in 
coordination with Software Test Engineering, the deliverable CSCI baseline 
configuration. 


8.2 Methods and Techniques 

After successful completion of formal FQT testing, Software Quality 
Engineering will bond the baselined software, identify, and label the media in 
coordination with Configuration Management per SQA and Configuration Management 
Procedures. Configuration Management then will control and store the media until 
delivery. 


Software Development Engineering in participation with Software Test 
Engineering will obtain a listing of the baselined CSCI software and verify that is is the 
correct version. 

8.3 Products 

The products produced are the baselined CSCI and the current listing of the 
CSCI which will be approved and certified by Software Test Engineering and Software 
Quality Engineering. This media and listing of the CSCI will be delivered as stated in 
Tables II and III. 
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Section 9 

ABBREVIATIONS AND ACRONYMS 


AR 

CDR 

CDRL 

CM 

CSCI 

DCR 

EOS/AMSU-A 

FQT 

NASA 

PAR 

SAP 

SCR 

SDR 

SQA 

SWAR 

TBD 


Acceptance Review 

Critical Design Review 

Contract Data Requirements List 

Configuration Management 

Computer Software Configuration Item 

Design Concepts Review 

Earth Observing System/ Advanced Microwave 
Sounding Unit-A 

Formal Qualification Test 

National Aeronautics and Space Administration 

Performance Assurance Requirements 

Software Assurance Plan 

Software Change Request 

Software Discrepancy Report 

Software Quality Assurance 

Software Assurance Review 

To Be Determined at some future date 
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Section 10 
GLOSSARY 


None. 
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Section 11 
NOTES 


11.1 Plan compliance with CDRL 309 

This plan incorporates the requirements of CDRL 309, NASA-DID-M400, 
NASA-DID-999 Sections 1, 2, 9, 10, 11, and 12, and the EOS Performance Assurance 
Requirements (PAR) for EOS General Requirements (GSFC #420-05-01) Section 10. A 
matrix is included in Appendix C which cross references this plan to the EOS 
Performance Assurance Requirements (PAR) for EOS General Requirements (GSFC 
#420-05-01) Section 10. The relationship of this plan to the NASA-DID-M400 is not 
included since the paragraphs are one-to-one with this plan. 

11.1.1 Compliance with NASA-DID-999 

The following table identifies the NASA-DID-999 Sections contained within 
this document as shown: 


NASA-DID-999 Contents 


Section 

In This 
Doc. 

N/A 

Added 

Marked 

with 

Pointer 

1.0 

Introduction 

X 





Related Documentation 

X 





Major Subsections 


X 



9.0 

Abbreviations and Acronyms 

X 




10.0 

Glossary 

X 




11.0 

Notes 

X 




12.0 

Appendices 

X 
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Appendix A 

Overall SW Description 

The software being developed for the EOS/AMSU-A program consists of 
the eight CSCI identified below and in Figure A-l. There are four CSCI for each of the 
Two instrument modules, EOS/AMSU-A1 and EOS/AMSU-A2. 



CSCI Name 

EOS/AMSU-A 1 

EOS/AMSU-A2 

1 . 

Command and Data Handling Firmware 

CSCI N8 

CSCI N12 

2. 

Instrument Control Firmware 

CSCI N7 

CSCI Nil 

3. 

Special Test Equipment Software 

CSCI N5 

CSCI N9 

4. 

Spacecraft Workstation Software 

CSCI N6 

CSCI N10 



394-3474X 


Figure A-l Description of EOS/AMSU-A CSCI 

Two CSCI are embedded Programmable Read Only Memory (PROM) within 
the AMSU-A instrument modules. One of the embedded flight CSCI is a version of the 
existing AMSU-A flight software modified to accommodate the MIL-STD-1553 interface 
bus protocol (Refer to Table A-I). The other embedded flight CSCI is the software to 
operate the MIL-STD-1553 interface itself (Refer to Table A-II). 


A-l 
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Table A-I Command and Data Handling Firmware CSCI 


CSCI NAME 

COMMAND AND DATA HANDLING FIRMWARE. EOS/AMSU-A1/A2 

CSCI No. 


N8/N12 

CHARACTERISTIC 

COMMENTS 

Type 

Deliverable-Mission Critical-Developed 
(S/W Acquisition Management Plan Para 4.6) 

Category 

Flight Firmware 

Language 

Assembly 

New Code 

Yes 

Mod Code 

No 

Development Host 

HP 64000-UX 

Firmware 

Yes 

Software 

No 

@ LOC 

100-500 


Table A-n Instrument Control Firmware CSCI 


CSCI NAME INSTRUMENT CONTROL FIRMWARE, EOS/AMSU-A1/A2 

CSCI No. N7/N11 

CHARACTERISTIC 

COMMENTS 

Type 

Deliverable-Mission Critical-Developed 
(S/W Acquisition Management Plan Para 4.6) 

Category 

Flight Firmware 

Language 

Assembly 

New Code 

Yes 

Mod Code 

No 

Development Host 

HP 64000-UX 

Firmware 

Yes 

Software 

No 

@ LOC 

IK 


Two of the CSCI are support software programs. One of the CSCI used in 
the GSE is a version of the existing AMSU-A GSE software modified to accommodate the 
MIL-STD-1553 interface bus protocol (refer to Table A-III). The other GSE CSCI is the 
software written in OASIS/CSTOL language and programming environment for the 
purpose of monitoring performance of the EOS/AMSU-A instruments at the spacecraft 
integration facility (refer to Table A-IV). See the Software Management Plan Report 
10339 (NASA-EOS/AMSU-A CDRL 005) for more information about the software. 
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Table A ID Special Test Equipment Software CSCI 


CSa NAME 

SPECIAL TEST EQUIPMENT. E0S/AMSU-A1/A2 

csaNo. 

N5/N9 

CHARACTERISTIC 

COMMENTS 

Type 

Deliverable-Mission Support-Heritage 
(S/W Acquisition Management Plan Para 4.6) 

Category 

Support GSE Software 

Language 

FORTRAN 

New Code 

No 

Mod Code 

Yes 

Development Host 

VAX/DEC 

Firmware 

No 

Software 

Yes 

@ LOC 

25K 


Table A-IV Spacecraft Workstation Software CSCI 


CSCI NAME 

SPACECRAFT WORKSTATION. E OS/AM SU-A1 /A2 

CSONo. 

N6/N10 

CHARACTERISTIC 

COMMENTS 

Type 

Deliverable-Mission Support-Developed 
(S/W Acquisition Management Plan Para 4.6) 

Category 

Support GSE Software 

COTS 

OASIS - (Operations and Science lnstru Support) Software System (Ada) 
CSTOL - (Colo Sys Test & Ops Language) CMD Language (Ada) 

SOLARIS -OPS System MOTIF -Windows Application 

TAE - (Trans Applications Envir) Workbench Interface With OASIS 
DATA BASE BUILDER - User Interface With DB 

New Code 

Yes 

Mod Code 

No 

Development Host 

Sun Sparc 10 

Firmware 

No 

Software 

Yes 

Procedures 

IN CSTOL - MACRO/CMD Sequence (Aerojet Develop) 

@ LOC 

None Data Base - Table 
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Appendix B 

SOFTWARE ASSURANCE FLOW DIAGRAM 
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Appendix C 


This Appendix is 
to the Performance Assurance 


a cross reference matrix to show the relation of this 
Requirements 420-05-01 Document Section 10.0. 


plan 
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Cross Reference Matrix 


Oar Sec. 10 
420-05 01 
Rqmt, 
Para. 

Requirement 


Comments 

10.1 

GENERAL REQUIREMENTS 

1.2, 1.3 


10.1a 

Brief Description of the Software 

1.2 


10.1b 

Management Organization, Structure and 
Responsibilities 

1.3 


10.1c 

Software Development and Control Process 

1.2, 1.3, 3.1 

Also see Tables 1, II, III.IV, A-l, 
ATI, ATM, and A-IV 

10.1d 

Software Design and Implementation Process 

3.1, 3.2 

Also see Table II, II, and IV 

10.1c 

General Assurance Process for Software 
Development 

3.1, 4.0, 5.0 

There is no special 
management or assurance 
practices, (see Tables! 
through IV, and A-l through 
A-IV.) 

10.1.1 

DOCUMENTATION 

3.1, 4.0 

See Table 1 

10.2 

VERIFICATION AND VALIDATION 

40,4.1,4.2 


10.2.1 

SOFTWARE TEST PLAN 

3.1, 3.3, 4.1 

See Table 1 

10.2.2 

SOFTWARE TEST PROCEDURES 

3.1, 3.3, 4.1 

See Table 1 

10.2.3 

SOFTWARE TEST REPORTS 

4.1, 4.3 

See Table 1 

10.2.4 

SOFTWARE WALK THROUGHS OR 
INSPECTIONS 
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